前言：為什麼我只是想改個資源卻要重建 Pod？

在 Kubernetes v1.33 之前，如果你想要調整 Pod 的 CPU 或記憶體配置，常見的做法只有兩條路：

1. 直接編輯 Pod：

   kubectl edit pod my-api
   

   嘗試修改 resources.requests/limits，結果不是被拒絕，就是只能：

   kubectl get pod my-api -o yaml > pod.yaml
   kubectl replace --force -f pod.yaml   # 本質是刪掉重建
   

   ＝服務中斷。

2. 修改 Deployment/StatefulSet 模板：

   kubectl set resources deploy my-api \
     --requests=cpu=250m,memory=512Mi \
     --limits=cpu=500m,memory=1Gi
   

   這會觸發滾動更新，舊 Pod 仍需被重建，還是避免不了中斷。

這就是痛點：調整資源 ≠ 重建 Pod。對長連線、stateful workload 或緊急救火的情境尤其不友善。

v1.33 帶來的改變：In‑Place Pod Resize（Beta）

• 可以直接對正在跑的 Pod 修改 container 的 CPU/Memory requests & limits，而不必重啟。
• 在 v1.33 已經進入 Beta 階段，多數發行版叢集會 預設開啟。
• 此功能自 1.27 Alpha 開始，如今逐步成熟，對 SRE 與開發團隊都是關鍵進展。

規則與限制（必看）

1. 只支援 CPU 與記憶體。暫不支援 ephemeral‑storage、自訂/延伸資源。
2. 降記憶體要小心：
   • memory requests 可以降。
   • 若要降 memory limits，該容器必須設 resizePolicy.memory=RestartContainer，否則會被拒絕。
3. QoS 類別不會改變：Guaranteed / Burstable / BestEffort 在 Pod 建立時就決定了，resize 不會改 QoS。
4. 控制器行為：Deployment/StatefulSet 模板改了會影響新 Pod，但舊 Pod 不會自動 in‑place 更新，需要你另外 patch。

實戰案例：零重啟調整 Pod 資源

範例 Pod

apiVersion: v1
kind: Pod
metadata:
  name: my-api
spec:
  containers:
  - name: app
    image: ghcr.io/example/my-api:1.0.0
    resources:
      requests:
        cpu: "100m"
        memory: "256Mi"
      limits:
        cpu: "200m"
        memory: "512Mi"

傳統作法（中斷式）

kubectl get pod my-api -o yaml > pod.yaml
# 修改 requests/limits
kubectl replace --force -f pod.yaml    # 舊 Pod 被刪 + 新 Pod 被建

v1.33 In‑Place 作法（零重啟）

kubectl patch pod my-api --type='merge' -p '{
  "spec": {
    "containers": [{
      "name": "app",
      "resources": {
        "requests": {"cpu": "500m", "memory": "512Mi"},
        "limits":   {"cpu": "1",    "memory": "1Gi"}
      }
    }]
  }
}'

驗證：

# 確認容器沒有重啟
kubectl get pod my-api -o jsonpath='{.status.containerStatuses[0].restartCount}{"\\n"}'

# 確認容器 ID 沒變
kubectl get pod my-api -o jsonpath='{.status.containerStatuses[0].containerID}{"\\n"}'

與 VPA 的差異

• VPA（傳統）：會先驅逐 Pod，再以新配置重建 → 中斷。
• In-Place Resize：直接 patch 現有 Pod → 無中斷。
• 預期未來 VPA/商用平台會結合 in-place，提供更平滑的垂直自動調整。

適用情境

• Stateful/長連線：資料庫代理、串流、AI 推理任務。
• 救火調整：流量暴增、CPU throttling，緊急加資源。
• FinOps/微調：透過監控數據精準做 rightsizing，降低成本。

實務建議

• 降記憶體盡量只降 requests，不要動 limits。
• 搭配監控/自動化：可寫 script 或 pipeline，偵測 CPU > 85% 時自動 patch 資源。
• 權限治理：可設命名空間白名單，讓團隊在不中斷的前提下自救。

總結

• 過去 kubectl edit 改 Pod 資源會被拒絕，或只能 replace --force → 中斷。
• v1.33 帶來的 In-Place Pod Resize（Beta），讓我們能在不中斷的情況下調整 CPU/Memory。
• 限制要記得：只能 CPU/Memory；降 memory limit 可能觸發重啟；QoS 不會變。
• 最適合用在 救火、stateful workload、FinOps 微調。未來若與 VPA/HPA 結合，將會是資源最佳化的強力武器。

延伸閱讀

• Kubernetes 官方 Blog：In-Place Pod Resize Beta
• Kubernetes Docs：Resize CPU and Memory Resources assigned to Containers